【レポート】あなたのオンプレミス DWH、 モダナイズしませんか︖ ー Amazon Redshift へのマイグレーションの⼿引き #AWS-07 #AWSSummit

【レポート】あなたのオンプレミス DWH、 モダナイズしませんか︖ ー Amazon Redshift へのマイグレーションの⼿引き #AWS-07 #AWSSummit

Clock Icon2021.05.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

この記事では、5月11日に行われた AWS Summit Online 2021 のオンラインセッション『あなたのオンプレミス DWH、 モダナイズしませんか︖ ー Amazon Redshift へのマイグレーションの⼿引き(AWS-07)』の模様をレポートします。

セッション概要

オンプレミス環境で構築された従来型のデータウェアハウス(DWH)では、各部門ごとに構築された DWH がそれぞれデータサイロとなってしまい、部門間でデータ連携を行って高度な分析を行うことが難しくなっています。この課題を解決するのが、データレイクと DWH が容易に連携可能であるモダンなデータ基盤です。Amazon Redshift は、クラウド上でモダンなデータ基盤を構築するために最適な DWHサービスです。本セッションでは、Amazon Redshift が選ばれる理由をご説明するとともに、マイグレーションのベストプラクティスをご紹介します。

登壇者

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 平間 大輔

レポート

Agenda

  • モダンなデータ基盤とは︖
  • Amazon Redshift が選ばれる理由
  • どのようにマイグレーションを⾏うか︖
  • マイグレーション ベストプラクティス
  • まとめ

モダンなデータ基盤とは?

従来のデータ基盤の課題

  • データサイロ化
    • 様々な部署が多様なデータを各々のBIシステムに蓄積しているが、部署間を横断したデータを加工したり活用するのが難しい
  • データ増大への対応
    • とくにオンプレミスはストレージ増強が追いつかない

この課題を解決するために「データウェアハウス(DWH) ー データレイク間を自由に連携できる」仕組みにすることがポイント。

Redshiftが選ばれる理由

Redshiftの特徴

  • レイクハウスアプローチ
    • DWHとして、S3データレイクや業務DBにわたる全データを一貫したセキュリティとガバナンスポリシーで分析できる
  • どのようなスケールでも高パフォーマンス
    • 自動チューニングシステムにより、他のDWHよりも約3倍のコストパフォーマンス
    • さらにAQUAではクエリが最大10倍高速に
  • スモールスタートが可能
    • インスタンスタイプによって、料金が予測可能、かつ使用した分だけ支払い

近年追加されたRedshiftの機能

  • お客様の要望に応じて機能追加されてきている

1.RA3 インスタンスと AQUA

  • 従来のインスタンス(DC、DS)はストレージとコンピュートが一緒のノードだったが、RAインスタンスはAmazon S3を利⽤し たマネージドストレージを採⽤し、コンピュート(処理能⼒)とストレージを分離して、柔軟なスケールアウトが可能に。コンピュートノード内の SSD はキャッシュとして利⽤し、⾼速処理を実現
  • マネージドスレージにアクセスする際にもパフォーマンスが落ちないように、分散型ハードウェアアクセラレーション処理レイヤ、AQUA (Advanced Query Accelerator) が利⽤可能に

2.Anazon Redshift Data Sharing

  • 複数のRedshiftノード間でデータ共有が可能(RAインスタンスでのみ利用可)
    • マネージドストレージを介して様々な部署で立ち上げたRedshiftの間でデータ共有が容易に
    • 従来のようなデータのインポート/エクスポートの必要がなく、アクセス権の管理と共有状況の監査によりセキュアなデータ共有ができる

3.クロス AZ クラスターリカバリー

  • クラスターを別のAZにフェールオーバー可能(RAインスタンスのみ利用可)
    • RedshiftもAZ障害にも対応できるように
    • 従来はスナップショットからのリストアの仕組みを作る必要があったが、その手間が省ける

マイグレーションの事例紹介

どのようにマイグレーションを行うか

プロジェクト面から見たマイグレーションの進め方

  • 主な方針として「既存環境の把握と移行方法の検討」→「業務システムや手順の影響洗い出し」→「新しいターゲットの作成、新旧システムの並行運用」→「マイグレーション」を検討

マイグレーションに役立つAWSサービス

  • AWS Schema Conversion Tool(AWS SCT) 、その他にAWS Database Migration Service(AWS DMS)もある

マイグレーションのための支援

  • セルフサービス
    • ステップバイステップガイドの利⽤やAWS エキスパートから援助を受けつつ、⾃分でマイグレーションを実⾏
  • マイグレーションサポート
    • Amazon Redshift への移⾏の各ステップで実践的なサポートを受けることが可能

DWH MIGRATION PROGRAM

  • データウェアハウスの移⾏を検討しているお客様向けの、移⾏⽀援プログラム(以下のアクティビティを無償提供)
    • AWS SCT が⽣成したレポートなどの情報を⽤いて、既存環境をアセスメント
    • Amazon Redshift の Technical dive deep トレーニング(半⽇)の実施
    • アセスメントを元に、移⾏リスクや PoC 項⽬を洗い出すワークショップの実施

Redshift導入を支援できるパートナー

マイグレーションベストプラクティス

技術⾯から⾒た、マイグレーションの進め⽅

  1. 既存環境と Amazon Redshift(移⾏先)で⽐較し、差異を把握する
    • 機能レベルまで視点を下げ、現在利⽤している機能を Amazon Redshiftと⽐較し、未対応の場合は代替機能で対応可能かを検討する
    • 現⾏環境の棚卸しを⾏い、アプリケーションがそのまま移⾏可能か、SQLなどの修正が必要か、など必要タスクの洗い出しも進める
  2. PoC を実施し、移⾏時に考えられる課題を洗い出す
    • AWS SCT での⾃動変換ができない DB オブジェクトやアプリケーションの修正⼯数
    • クエリの性能要件を満たすためのクラスターのサイジング
    • データ移⾏の⼿順と処理時間の確認
  3. PoC で得た知⾒をもとに、アプリケーション改修、データ移⾏、先⾏実施するシステムの選択と並⾏稼動の検討などの移⾏計画を策定し、実⾏に進める

マイグレーションで活⽤したい Amazon Redshift の機能

  • DDL、ストアドプロシージャ、SQL スクリプトの移⾏には
    • ストアドプロシージャのサポートにより、レガシーなプロシージャの移植が簡単に
    • Lambda UDF (ユーザー定義関数) が、C, C++, Java の UDF とマクロのサポートを拡張
  • 移⾏後のクエリにパフォーマンス課題がある場合
    • マテリアライズド・ビューは、BI ダッシュボードのクエリといった複雑なクエリを移⾏する際、パフォーマンスの改善に役⽴つ
  • Amazon Redshift へ直接データを投⼊できない・しない場合は
    • イメージファイル、PDF、その他のバイナリデータといった LOB(ラージオブジェクト)は直接サポートはされていないが、Amazon S3 への移⾏が可能
    • 外部テーブルとアクセス頻度の低いデータには、Amazon RedshiftSpectrum を活⽤

まとめ

所感

漠然とRedshiftにマイグレーションしたい、という思いから具体的なアクションをどのように検討すれば良いかをよく理解できるセッションでした。

プロジェクト面、技術面の両方から方法をアプローチしていますので、移行を検討しているチームの皆さんで試聴して意識の共有をはかると良いかもしれません。

あわせて読みたい

実際Redshiftってどれくらいのパフォーマンスなのかイメージしづらい方は、弊社の検証ブログも参考にしてみてください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.